Add self-hosted macOS HVF runtime job to CI#91
Open
Max042004 wants to merge 1 commit into
Open
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Max042004
changed the title
Max042004
force-pushed
the
ci/macos-hvf
branch
2 times, most recently
from
b18134f to
5186357
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Contributor
|
Refine the descriptions of both pull request body and commit message to address the close of #51 . |
Max042004
force-pushed
the
ci/macos-hvf
branch
2 times, most recently
from
2e06673 to
a30de42
Compare
Max042004
changed the title
Max042004
force-pushed
the
ci/macos-hvf
branch
5 times, most recently
from
4ec266d to
64ff85b
Compare
Contributor
|
Explain the blocking issues to proceed. |
Hypervisor.framework needs real Apple Silicon hardware, so the hosted build-macos job can only compile elfuse and check the entitlement, never boot a guest. Add a runtime-macos job on a self-hosted Apple Silicon runner ([self-hosted, macOS, arm64]) that actually exercises the VM under HVF. The job is scoped to the upstream repository with github.repository == 'sysprog21/elfuse', so it runs for pushes to main and for pull_requests targeting main -- including PRs opened from a collaborator's fork -- but never inside a fork's own Actions context, so a branch pushed to a fork without an upstream PR triggers nothing. Untrusted outside fork PRs are held by the repository's "require approval for outside collaborators" setting, so a maintainer still gates every outside run without needing a head-ref guard or a label. The job runs after build-macos, serializes per ref through a concurrency group, and cancels in-progress runs only for pull requests. It asserts the host is arm64, reports kern.hv_support, caches and installs just the missing Homebrew packages (binutils, qemu), and fails early with install guidance when Rosetta for Linux is absent. After make elfuse it confirms the com.apple.security.hypervisor entitlement is codesigned into build/elfuse, then runs test-hello, test-multi-vcpu, make check, and tests/test-matrix.sh all.
jserv
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GitHub-hosted macOS runners do not expose Apple's Hypervisor.framework (HVF):
the hosted runner OS itself runs inside a virtualization layer that withholds
HVF, so
hv_vm_create()returnsHV_UNSUPPORTED. Because of this, the existingbuild-macosjob can only compile elfuse and verify the HVF entitlement — itcan never actually boot a guest.
This PR adds a
runtime-macosjob that runs on a self-hosted Apple Siliconrunner (an M4 machine) where HVF is available, so the real runtime path —
booting a Linux guest under HVF + Rosetta — is exercised in CI for the first
time. The hosted
build-macosjob is unchanged and keeps gating builds asbefore; this job runs after it (
needs: build-macos).Closes #51.
Note
Known failure: the
runtime-macosjob currently fails in themake check. Once #76 lands (or is merged into / rebased onto this branch),it is expected to go green.
What the
runtime-macosjob doesruns-on: [self-hosted, macOS, arm64],needs: build-macos, 20-minutetimeout.
mainruns finish.Where it runs (trigger gating)
main— runs. Apull_requestfrom any fork is evaluatedin the upstream (
sysprog21/elfuse) Actions context, so a collaborator whopushes a branch to their own fork and opens a PR against upstream gets the
full runtime suite. This is the normal contributor flow and must work.
main— runs. Post-merge validation on the mainline.Failing fast on superseded re-runs
There is only one self-hosted runner, so a wasted run on it blocks every other
PR. Per-ref
concurrencyalready cancels an in-progress run when a newer commitis pushed to the same PR, but it does not cover a manual Re-run jobs on an
old run: a re-run replays the original (now stale) commit and would otherwise
occupy the runner for the full timeout re-testing code that is no longer HEAD.
The job's first step compares the run's frozen
head.shaagainst the PR's liveHEAD (via the REST API) and, when they differ, prints a
::error::saying thecommit is no longer the latest and
exit 1, end up failed.